Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve main #6053

Open
wants to merge 10 commits into
base: master
Choose a base branch
from
Open

Conversation

matthias-ronge
Copy link
Collaborator

The main class was well hidden as KitodoVersionListener. I renamed it to KitodoProduction and moved it. (Git doesn't get this on top of each other and show them as new, but it is from the previous class KitodoVersionListener. If you look at the individual commits, it becomes more understandable.) The instance exposes its essential properties, and the main class now handles essential functions of starting and stopping Active MQ and stopping the task manager, that was previously scattered throughout the application. The version is now no longer returned statically, but rather out of the main class.

I find it tidier this way.

Copy link
Collaborator

@henning-gerhardt henning-gerhardt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is a code reading review only. I can not test the changes it self. But from reading everything looks good.

@solth
Copy link
Member

solth commented May 23, 2024

@matthias-ronge please rebase against current master, since there are code conflicts and this pull request is the next merge candidate.

Copy link
Member

@solth solth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just some small remarks. @matthias-ronge I know you just moved functionality to the new KitodoProduction.java file and didn't author it, but I think this is a good occasion to check the code for potential improvements, if they are low cost.

startActiveMQ();
}

private static final Optional<Manifest> retrieveManifestFileAsStream(ServletContext context) {
Copy link
Member

@solth solth Jul 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
private static final Optional<Manifest> retrieveManifestFileAsStream(ServletContext context) {
private static Optional<Manifest> retrieveManifestFileAsStream(ServletContext context) {

My IDE reports: "Such code might indicate an error or an incorrect assumption about the effect of the final keyword. Static methods are not subject to runtime polymorphism, so the only purpose of the final keyword used with static methods is to ensure the method will not be hidden in a subclass."

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I once did read that one should make all methods used in the constructor final, because if they are overloaded in a subclass, it could have confusing effects. I always do that; if the methods are under the constructor, you can see nicely in the “outline” what belongs to the constructors and where the actual class begins. For me, that is an improvement in the clarity of the code. In this case, it is particularly exciting because the “constructor” is not a constructor in the Java sense, but a method that is called by the Servlet Container to construct the class.

outline_

Copy link
Member

@solth solth Aug 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not convinced having a structure outline in your IDE that you find more intuitive is a good enough reason to overrule this formal recommendation, but I can live with it if you really think it helps you.

*
* @return the servlet context
*/
public ServletContext getServletContext() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this method? My IDE shows it is unused, and the two interfaces that this method implements do not seem to require the method either.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's just a getter. You might want to get the servlet context to get the application's working directory, for example, or the server version. It's here for convenience. At the moment, it's not used yet.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove the method if it's unused and not required at the moment. Doesn't matter if it's just a getter. It should be added if required in the future.

*
* @return the manifest
*/
public Optional<Manifest> getManifest() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See above.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is my idea that the main class of the application also provides essential characteristics of the application via getters. The manifest is such.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove unused getters if they are not technically required, see above.

Copy link
Member

@solth solth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove unused getters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants